In situations where a runtime system (Web Services endpoint) has available multiple Web Services stacks, the deployer has to choose the target deployment stack. The stacks will have differing functional and non-functional capabilities.
The deployer needs to understand both the relative functional and non-functional capabilities of the Web Services stacks and the tradeoffs between them. Individual Web Services may exploit or require different subsets of these capabilities and therefore the optimal stack for deployment of one Web Service may not be the optimal stack for another, again the deployer must choose and configure the appropriate stack. This choice requires significant knowledge of the stacks' characteristics as well as of the individual Web Service's requirements and is thus a time consuming and error prone process.
WS-Policy (www.w3.org/Submission/WS-Policy/) provides a standard mechanism for a Web Services provider to describe these functional and non-functional requirements and capabilities. The WS-Policy includes the following paragraphs.
WS-Policy provides a flexible and extensible grammar for expressing the capabilities, requirements, and general characteristics of entities in an XML (eXtensible Markup Language) Web services-based system. WS-Policy defines a framework and a model for the expression of these properties as policies.
WS-Policy defines a policy to be a collection of policy alternatives, where each policy alternative is a collection of policy assertions. Some policy assertions specify traditional requirements and capabilities that will ultimately manifest on the wire (e.g., authentication scheme, transport protocol selection). Other policy assertions have no wire manifestation yet are critical to proper service selection and usage (e.g., privacy policy, QoS (quality of service) characteristics). WS-Policy provides a single policy grammar to allow both kinds of assertions to be reasoned about in a consistent manner.”
Applied in the Web Services model, policy is used to convey conditions on an interaction between two Web Service endpoints. Satisfying assertions in the policy usually results in behavior that reflects these conditions. Typically, the provider of a Web service exposes a policy to convey conditions under which it provides the service. A requester might use this policy to decide whether or not to use the service. A requester may choose any alternative since each is a valid configuration for interaction with the service, but a requester MUST choose only a single alternative for an interaction with a service since each represents an alternative configuration.
A policy assertion is supported by a requester if and only if the requester satisfies the requirement (or accommodates the capability) corresponding to the assertion. A policy alternative is supported by a requester if and only if the requester supports all the assertions in the alternative. And, a policy is supported by a requester if and only if the requester supports at least one of the alternatives in the policy. Note that although policy alternatives are meant to be mutually exclusive, it cannot be decided in general whether or not more than one alternative can be supported at the same time.”
In general WS-Policy is used by a provider to communicate these requirements to a requester and sometimes by a requester to validate that a given provider meets some level of required behavior.